Organizing medical images for display

ABSTRACT

The subject matter of this specification can be implemented in, among other things, a system for interfacing with multiple medical imaging modalities that includes a manifest generator for generating a manifest of medical images. The manifest can be used to determine an ordering or a layout of the medical images generated by the modalities, optionally as a function of the modality type, anatomical area, and other variables. In some embodiments, the various medical images and metadata may be received at an image order management system that parses the metadata and assembles the metadata into the manifest files that may be transmitted independently to remote interpretation sites, which in turn may be equipped with image viewer applications that analyze the manifest files and determine a rearranged ordering and/or grouping of the medical images, wherein the rearrangement is executed as a function of modality, anatomy, orientation and other variables.

BACKGROUND

Medical facilities, such as hospitals, include imaging modalities for creating medical images of patients. For example, an x-ray image can be created using a radiography device. A CT image can be created using a computed tomography device. An MRI image can be created using a magnetic resonance imaging device.

A radiologist interprets the medical images, either at the modality or at a radiologist workstation. An image viewer application at the workstation receives the medical images and presents the medical images to the radiologist. The radiologist reviews the medical images and provides a report based on an analysis of the medical images. For example, the radiologist may provide a diagnosis of a particular medical condition, such as a gun shot wound or a tumor, based on the medical images.

Typically, the medical images are in a Digital Imaging and Communications in Medicine (DICOM) format. The DICOM format includes metadata that describes the medical images. The metadata can, for example, describe an ordering and/or grouping in which to present the medical images. The image viewer application can receive the medical images and present the medical images in the ordering and/or grouping described in the metadata.

In some cases, the radiologist workstation where the images are interpreted is within the hospital or medical facility. In other cases, the workstation is remote from the hospital, such as in a teleradiology system. In a teleradiology system, the hospital or medical facility transmits the medical images to a teleradiology system. Radiologists may review the medical images at the teleradiology system or the teleradiology system may transmit the medical images to a remote radiologist's workstation.

SUMMARY

A system for interfacing with multiple modalities may include a manifest generator that generates a manifest of medical images received from the modalities. The manifest is used to determine an ordering or a layout of the medical images generated by the modalities, optionally as a function of the modality type, anatomical area, and other variables. In an illustrative implementation, multiple modalities may generate medical images that have embedded metadata that specifies the modality that generated the images, a default grouping of the images, and a default ordering of the images within the groups, wherein the default ordering and grouping may be specific to particular types of modalities or facilities. In some embodiments, the various medical images and metadata may be received at an image order management system that parses the metadata and assembles the metadata into manifest files that may be transmitted independently to remote interpretation sites, which in turn may be equipped with image viewer applications that analyze the manifest files and determine a rearranged ordering and/or grouping of the medical images, wherein the rearrangement is executed as a function of modality, anatomy, orientation and other variables. In such implementations, the remote interpretation site's image viewer application may call for the transmittal or caching of images depending on the revised ordering and grouping.

The systems and techniques described here may provide one or more of the following advantages. First, a system can display one or more sequences of medical images based on medical relevance regardless of an original sequence in which the medical images were generated by a modality. Second, a system can provide a medical image that is displayed as part of several differently ordered sequences of medical images. Third, a system can provide a manifest file including copied medical image metadata that can be transmitted or received independently of the medical images the manifest file describes, where the manifest file is accessed to quickly reorder medical images into medically relevant sequences. Fourth, a system can provide one or more sequences of medical images having a consistent organization and layout for medical images received from a number of different modalities or medical facilities despite the modalities' and/or the facilities' transmission of the medical images in disparate sequential orders. Fifth, a system can provide correction of image series names or image series identifiers provided by a modality or medical facility. Sixth, a system can provide an efficient layout and organization of medical images for reviewing the medical images. Seventh, a system can provide a consistent organization of medical image sequences and ordering within the sequences to enable an automatic diagnosis of the medical images.

The details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIGS. 1A-B are diagrams showing an example of a teleradiology system for organizing images by medical relevance.

FIG. 2 shows an example of a graphical user interface for presenting images organized by medical relevance.

FIG. 3 shows an example of a graphical user interface for presenting images organized by medical relevance.

FIG. 4 is a flow chart showing an example process for creating a manifest file for use in organizing images by medical relevance.

FIG. 5 is a flow chart showing an example process for presenting images organized by medical relevance.

FIG. 6 is a schematic diagram showing an example of a generic computing system that can be used in connection with computer-implemented methods described here.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

In some implementations, the organization is based on a medical relevance of the medical images. For example, the medical images can include or be associated with metadata. Metadata is data that describes other data. In illustrative embodiments, the metadata is data that describes the medical image data. The metadata can be extracted from the medical images and compiled into a manifest file that, for example, serves as a catalog, or manifest, of the medical images. In some implementations, the manifest file can be used to reorder the medical images for presentation to medical personnel. For example, the manifest file may include information specifying an orientation of each medical image. The medical images can then be reordered according to a desired orientation (e.g., sagittal).

FIG. 1A is a schematic diagram showing an example of a teleradiology system 100 for organizing medical images by relevance. The teleradiology system 100 includes an image order management system (IO management system) 102, one or more medical facilities 104 a-b, and one or more client devices 106 a-b. The IO management system 102, the medical facilities 104 a-b, and the client devices 106 a-b may be connected by one or more networks, such as the Internet or a wide-area-network. The medical facilities 104 a-b may send one or more medical images 108 a-f of a patient along with orders for studying the medical images 108 a-f to the IO management system 102. The orders are requests from the medical facilities 104 a-b to review the medical images 108 a-f. The orders include instructions for reviewing the medical images 108 a-f.

In some implementations, the IO management system 102 generates one or more manifest files that summarize one or more metadata 110 a-f included in the medical images 108 a-f. For example, the IO management system 102 may extract the metadata 110 a-c from the medical images 108 a-c and the metadata 110 d-f from the medical images 108 d-f. The IO management system 102 may generate one or more manifest files 112 a-b that include the metadata 110 a-c and the metadata 110 d-f, respectively. The IO management system 102 can send the medical images 108 a-c to the client device 106 a independently of sending the manifest file 112 a to the client device 106 a. Similarly, the IO management system 102 can independently send the medical images 108 d-f and the manifest file 112 b to the client device 106 b. The client devices 106 a-b may use the manifest files 112 a-b to reorder the medical images 108 a-c and 108 d-f, respectively.

In particular, the medical images 108 a-f may include representations of body parts created using a modality such as a radiography (x-ray) device, a computed tomography (CT) device, a magnetic resonance imaging (MRI) device, or an ultrasound device. In some implementations, the medical images 108 a-f contain the metadata 110 a-f, respectively, which describes the associated medical image. For example, the medical image 108 a includes the metadata 110 a. The metadata 110 a can include information, such as an identifier of the medical facility 104 a that sent the medical image 108 a, the number of medical images in the order, the patient name, an identifier of each medical image in the order, the type of modality that created the medical image 108 a, configuration parameters of the modality used to create the medical image 108 a (e.g., the time between injecting a contrast agent and generating an image or the orientation at which the image was generated with respect to the patient), and other information related to the medical image 108 a.

In some implementations, the medical images 108 a-f may be created and transmitted using the Digital Imaging and Communications in Medicine (DICOM) standard. In some implementations, the metadata 110 a is embedded in a file that includes the medical image 108 a. For example, the metadata 110 a may be included in header fields that accompany the medical image 108 a, where the header fields and the medical image 108 a are transmitted together. In another example, an external requirement or regulation that applies to the medical image 108 a may restrict separation of the metadata 110 a from the medical image 108 a (e.g., for compliance with the DICOM standard).

In some implementations, the medical facilities 104 a-b generate the medical images 108 a-f, which include the metadata 110 a-f, and send the medical images 108 a-f to the IO management system 102. The IO management system 102 can include an image server 114 that receives the medical images 108 a-f. The image server 114 stores the medical images 108 a-f in an image storage 116.

In some implementations, the image server 114 may be part of a Picture Archive and Communication System (PACS), which may digitally store, transmit, and facilitate the display of radiology images. The image server 114 extracts the metadata 110 a-f from the medical images 108 a-f. The image server 114 uses the metadata 110 a-c to generate the manifest file 112 a and the metadata 110 d-f to generate the manifest file 112 b. The manifest files 112 a-b can include metadata from the medical images 108 a-f that is medically relevant to the review of the medical images 108 a-f. The image server 114 stores the manifest files 112 a-b in the image storage 116.

FIG. 1B is a block diagram showing an example of additional components in the IO management system 102. The IO management system 102 can include an interface 118, a metadata extractor 120, and a manifest generator 122.

The IO management system 102 uses the interface 118 to send and receive files or other data. For example, the IO management system 102 can receive the medical images 108 a-c from the medical facility 104 a through the interface 118. In some implementations, the IO management system 102 can send the medical images 108 a-c and the manifest file 112 a to the client device 106 a through the interface 118.

The metadata extractor 120 extracts metadata from medical images. For example, the metadata extractor 120 can retrieve the medical images 108 a-c from the image storage 116 and extract the metadata 110 a-c, respectively. In another example, the metadata extractor 120 can receive the medical images 108 a-c from the interface 118 and extract the metadata 110 a-c, respectively. The metadata extractor 120 provides extracted metadata to the manifest generator 122. In some implementations, the metadata extractor 120 stores the extracted metadata, for example, in the image storage 116.

The manifest generator 122 uses extracted metadata to generate manifest files. For example, the manifest generator 122 can receive the metadata 110 a-c from the metadata extractor 120 and generate the manifest file 112 a. In another example, the manifest generator 122 can retrieve the metadata 110 a-c from the image storage 116 and generate the manifest file 112 a. In some implementations, the manifest generator 122 stores the generated manifest files, for example, in the image storage 116. The IO management system 102 provides the manifest file 112 a to the client device 106 a through the interface 118.

The IO management system 102 assigns the orders to appropriate medical personnel at the client devices 106 a-b. For example, the IO management system 102 may assign an order from the medical facility 104 a to a radiologist, doctor, or other medical personnel at the client device 106 a. If the radiologist accepts the order, the IO management system 102 may make the medical images 108 a-c and the manifest file 112 a associated with the order available to the radiologist for viewing.

The client device 106 a receives the manifest file 112 a from the IO management system 102. The client device 106 a may use the manifest file 112 a to reorder the medical images 108 a-c into one or more medically relevant sequences of images. For example, the original order of the medical images 108 a-c as generated by a modality of the medical facility 104 a may be a single series of images. The client device 106 a can, for example, divide the medical images 108 a-c into separate sequences for each image orientation. For example, the metadata 110 a-c may include orientation information that describes one or more of the medical images 108 a-c as axial images, sagittal images, coronal images, and/or oblique images. The client device 106 a creates a separate sequence (or stack) of images for each of the image orientations.

In some implementations, a medical image can be included in more than one sequence. For example, if an axial sequence of images and a sagittal sequence of images exist where the sagittal sequence of images has a small number of images (e.g., one to five images), then the client device 106 a can create a scout sequence and place the sagittal images in the scout sequence. A scout sequence of images can be a map of the locations at which the corresponding axial images were created. For example, a scout image can include a sagittal (e.g., side) view of the patient. The scout image can include markers that indicate the locations at which corresponding axial images were taken.

In some implementations, if a scout sequence is identified then the corresponding sagittal sequence is removed. In some implementations, another orientation can be determined to be a scout sequence, such as a coronal sequence or an oblique sequence that is nearly sagittal or coronal.

The client device 106 a can present the reordered sequences of images to the radiologist. The radiologist may interpret the medical images 108 a-c and send a report back to the IO management system 102. The IO management system 102 may then forward the report to the medical facility 104 a, where the report may be used in a diagnosis for the patient.

In some implementations, rather than present (or in addition to presenting) the medical images 108 a-c to a radiologist, the client device 106 a includes an image interpretation application for automatically reviewing or diagnosing the medical images 108 a-c. In some implementations, the consistent organization of image sequences and ordering of images within the image sequences can provide a more reliable interpretation by the image interpretation application than inconsistent sequences or inconsistent ordering from various modalities or medical facilities.

In some implementations, the image interpretation application performs an automated preliminary review or initial diagnosis of the medical images 108 a-c. For example, the image interpretation application can determine one or more biological differences between images, such as between an image taken some time in the past and a currently reviewed image, two images near one another, or an image from a healthy patient and an image from the patient being reviewed. In one example, the image interpretation application can compare the reordered medical images to past medical images associated with the same patient depicted in the reordered medical images to determine biological differences between the compared medical images.

In some implementations, the image interpretation application can consult stored diagnosis-making information. The image interpretation application can construct the initial diagnosis from a portion of the diagnosis-making information associated with an anatomical area in which the biological differences occur, such as a head, a chest, an abdomen, an arm, or a leg, to name a few. The diagnosis-making information used by the image interpretation application can also be associated with a particular type of the determined differences. The preliminary review may identify points of interest in an image to be brought to the attention of a radiologist. For example, the image interpretation application can highlight the determined biological differences for review by one or more medical personnel.

The IO management system 102 may be implemented on a single computing device or on multiple computing devices, such as a server farm. In one implementation, the IO management system 102 may be disbursed over several servers that may be connected through a network. This configuration may be advantageous by permitting easy expansion of the system and flexibility in managing the flow of received and output images and orders.

Medical facilities may send images and orders at the same time as one another or at different times. Images, orders, and reports may be sent over the same network or different networks. For example, the IO management system 102 may receive images and orders through a single T1 connection to the Internet, or the images may be received from the Internet through a T1 connection and the orders may be received through a modem connection. In another example, the IO management system 102 may receive an image and an order from a medical facility over the Internet and return a corresponding report to the medical facility over a fax connection.

Additionally, the images and orders may be sent separately or combined in one transmission. For instance, a computing device at a medical facility may use software that sends the orders and the images with a single application and single set of actions, or the medical facility may send the images using one application that sends one transmission and send the orders using a different application that sends a separate transmission.

The network over which the images and orders are sent from the medical facilities 104 a-b to the IO management system 102 may be a secure network, such as a virtual private network (VPN). The VPN may include a secure computing device, or terminal, at the medical facility, encrypted transmissions sent through the network, a secure computing device at the IO management system 102, and a secure computing device at the client devices 106 a-b. The transmission of encrypted images and orders may also include the use of other forms of secure communications, such as the Secure Socket Layer (SSL), Terminal Services, and Citrix systems.

In one implementation, the IO management system 102 may link multiple images relating to one patient together. A medical facility may transmit two or more sets of images for the same patient at different times. The IO management system 102 may take the received images and associate them with one another using several factors to determine if the images should be transmitted to the same radiologist for analyzing. These factors may include information, such as a patient identifier, a facility identifier, the time and date each image was sent, and the patient's medical record number. This information may be stored for each image in a database implemented at the IO management system 102. If the images' patient identifier, facility identifier, and medical record number match, and if the second image set is within a predetermined time period, the images may be transmitted to the same radiologist. Information about where each image was transmitted may also be stored in the database.

For example, patient Bob Jones has a CT scan of his abdomen on Tuesday night, and later that night has a CT scan of his chest. Both image scans take place at Memorial Hospital. The IO management system 102 may receive the abdomen CT first and assign it to radiologist Laura Wilder. When the System later receives the chest image, the workflow module may query the database to determine if any previous images were received during that night for patient Bob Jones, from Memorial Hospital, with Jones' medical record number. The IO management system 102 may find that a previous image of Bob Jones' abdomen was received and transmitted to Dr. Wilder. The IO management system 102 may then transmit the later chest image to Dr. Wilder for analyzing. Additionally, orders or reports may also be linked in the way using the information described above to transmit orders or reports for the same patient to the same radiologist. In another example, Dr. Wilder may receive images of Jones that were taken days, weeks, or years before.

In another implementation, the radiologist may receive all prior images, orders, reports, or any combination thereof that are related to a patient regardless of when they were transmitted or if they were originally transmitted at all. The IO management system 102 may query a medical data storage system at the medical facility 104 a that is requesting the current order to determine if it contains any prior images, orders, and reports. If so, the IO management system 102 may request the information and transmit it to the radiologist who may view the current images. The prior information may be bundled with the current image or it may be sent to the radiologist in a separate transaction.

Additionally, the IO management system 102 may query medical data storage systems at medical facilities that are located within a geographic radius (such as a three county radius, within the state, or within the country) of the medical facility 104 a that transmits the current image. Prior information associated with the patient may be harvested from multiple facilities and transmitted to the radiologist. In another implementation, the IO management system 102 may query all medical facilities networked to the IO management system to harvest information to transmit to the radiologist. Additionally, an alert may be transmitted to the radiologist that prior information relating to the patient exists. Alternatively, the IO management system 102 may transmit a request to the medical personnel at the medical facility 104 a to transmit prior information about the patient to the IO management system 102.

In some implementations, the medical images 108 a-c include linked images and/or related images as described above. The linked images and/or related can be received from the medical facility 104 a or from a storage device at the IO management system 102. The image server 114 can include metadata from the linked images and/or the related images in the manifest files 112 a-b. The linked image and/or related image metadata can be used by the client device 106 a to reorder the medical images 108 a-c.

As previously described, the image server 114 extracts metadata from the medical images 108 a-f, such as patient and medical facility information. One or more image data sources, such as a modality for creating medical images or other image capturing device sends the medical images to a hospital imaging server, such as a Digital Imaging and Communications in Medicine (DICOM) server. The hospital imaging server sends the medical images to the IO management system 102. Each image data source may have a different process for organizing sequences of medical images. In some implementations, the same type of modality and/or the same type of image may have different sequence organization when generated at two different image data sources. In some implementations, the image server 114 uses the extracted metadata to create sets of images with a consistent ordering or sequence for similar images (e.g., irrespective of modality manufacturer or a particular configuration of a modality).

In some implementations, each client device may contain a computing device with components necessary to display the medical images, read the orders, and return a report based on examination of the medical images. For example, the client device 106 a may include a computing device with a display and an image decompressor and/or decoder. The client device 106 a receives the medical images 108 a-c transmitted by the IO management system 102, decompresses the images using a decompressor, and displays the images using an image viewer and a display device. The image decompressor may be implemented on the computing device, or on a separate computing device, and use decompression algorithms, such as the decompression algorithms associated with JPEG, JPEGLS, and JPEG “2000.” The images may be cached at the client devices 106 a-b. For example, the images may be saved to a local storage device in the client device 106 a. In one implementation, only the medical images 108 a-c, which are associated with a particular order, assigned to and accepted by a radiologist may be viewed at the client device 106 a. In another implementation, the radiologist may view images of former orders accepted by the radiologist or orders that the radiologist plans to accept. In other implementations, the radiologist may view images regardless of whether the order is or will be accepted.

Additionally, the client devices 106 a-b may contain more than one computing device. For instance, there may be one computing device that accepts the images, decompresses them, and displays the images for the radiologist. The other computing device may handle receiving the orders, displaying them to the radiologists for acceptance, receiving the report from the radiologist, and transmitting the report to the IO management system 102.

While the examples shown in FIGS. 1A-B include a few medical images, the IO management system 102 can receive a number of medical images associated with a particular order that is significantly larger than a few images, such as hundreds or thousands of images. In addition, a medically relevant sequence of images can include any of the medical images received from a medical facility as determined by processing of the associated manifest file. Additionally, the medically relevant sequence may only include a portion of the medical images generated by a modality at a medical facility,

FIG. 2 shows an example of a graphical user interface (GUI) 200 for presenting medical images organized by medical relevance. The GUI 200 can be provided by an image viewer application. Particularly, the GUI 200 shows sequences of CT images that may be medically relevant for an examination of the abdomen and pelvis of a particular patient. The GUI 200 includes multiple viewing panes 202 a-c and multiple thumbnails 204 a-e. Each of the viewing panes 202 a-c shows an image from a particular medically relevant sequence of images.

The viewing pane 202 a shows a sequence of sagittal images of the patient's abdomen. The sagittal view is a scout sequence as indicated by the thumbnail 204 b that corresponds to the sagittal view in the viewing pane 202 a. The viewing pane 202 b shows a sequence of axial images of the patient's abdomen without a contrast agent. When introduced into the patient, the contrast agent changes the intensity of the various types of tissue shown in the CT images. The viewing pane 202 c shows a sequence of axial images of the patient's abdomen with a contrast agent. The highlighted borders of the thumbnails 204 b and 204 d-e indicate that the sagittal scout sequence, the axial sequence without the contrast agent, and the axial sequence with the contrast agent are currently presented in the viewing panes 202 a-c.

The viewing panes 202 b-c may be linked so that scrolling one to a particular image in the sequence also scrolls the other pane to a corresponding image in the other sequence. For example, if the radiologist scrolls the viewing pane 202 b to image index number five in the sequence of images without contrast agent, then the GUI 200 scrolls the viewing pane 202 c to image index number five in the sequence of images with contrast agent.

The viewing pane 202 a includes a horizontal indicator 206. The horizontal indicator 206 is also linked to the viewing panes 202 b-c. As the radiologist scrolls through the images in the viewing panes 202 b-c the horizontal indicator 206 can show the position of the images along the patient's abdomen.

Each of the viewing panes 202 a-c can show metadata that is included in the images being presented. For example, each of the images include, and the viewing panes 202 a-c present, metadata including a patient name, a patient identifier, a patient birth date, medical technician comments, a time the particular image was taken, a position of the image relative to the patient, a DICOM series number (“series #”) that the image was originally included in, and the order of the image (“index”) in the DICOM series. In some implementations, this can be retrieved from the DICOM information embedded in the displayed image. In some implementations, this information can be retrieved from the manifest file.

In this example, the image viewer application that generates the GUI 200 received a manifest file that describes a set of CT images. The original CT images were organized into two DICOM series, a scout series and an axial series. The image viewer uses the copied metadata in the manifest file to determine that the axial DICOM series includes axial images with and without a contrast agent, and the scout DICOM series includes a small number of sagittal images. For example, the first half of the images in the axial series may include the axial images without the contrast agent and the second half of the images may include the axial images with the contrast agent.

DICOM metadata associated with the first half of the images may include information specifying that the images are axial images without the contrast agent. Similarly, the second half of the images may include information specifying that the images are axial images with the contrast agent. This information can be extracted for inclusion in the manifest file.

The image viewer may perform a sequence creation rule using the manifest file. For example, if the images include axially oriented images with contrast agent then create a sequence for axial images with contrast agent. In addition, if the images include axially oriented images without contrast agent then create a sequence for axial images without contrast agent. In some implementations, a further rule may be used to remove a sequence. For example, the original axial DICOM series can be removed if the axial sequences with and without contrast agent otherwise include all of the images from the axial DICOM series. In addition, default sequences can be created. For example, an “all” sequence can be created that includes all of the images. In this way an image can be included in multiple sequences. For example, an axial image can be included in the all sequence, the sequence for the axial DICOM series, and the axial sequence without contrast agent.

The image viewer further performs sequence inclusion rules upon each of the received medical images. If the DICOM metadata in the manifest file indicates that a particular image is axial and a contrast agent was used, then the image is included in the axial sequence of images with contrast agent. If the DICOM metadata in the manifest file indicates that a particular image is axial and no contrast agent was used, then the image is included in the axial sequence of images without contrast agent. If the DICOM metadata in the manifest file indicates that a particular image is sagittal and there are a small number of other sagittal images, then the image viewer determines that the image is a scout image. In some implementations, the scout images are not identified within the DICOM metadata.

In some implementations, the generated sequences can be represented by the thumbnails 204 a-e. The thumbnail 204 a represents the all sequence. The thumbnail 204 b represents a sequence for the original DICOM scouts series (“series #: 1”). The thumbnail 204 c represents the sequence for the axial DICOM series. The thumbnail 204 d represents the axial sequence of images without contrast agent. The thumbnail 204 e represents the axial sequence of images with contrast agent. A radiologist can select one or more of the thumbnails 204 a-e for presentation in the GUI 200. In some implementations, a sequence can have viewing rules (e.g., a hanging protocol). The viewing rules can include, for example, the number of panes, arrangement of panes, and content of the viewing panes. In this example, CT scout images are placed in a top viewing pane, CT images without contrast agent are placed in a lower left viewing pane, and CT images with a contrast agent are placed in a lower right viewing pane. This may represent a default hanging protocol upon receiving the manifest file and the medical images.

In some implementations, the image viewer determines a name for the sequence. For example, “series #1” from the DICOM metadata may have been labeled as “sagittal.” The image viewer determines that because the orientation metadata of the images indicates a sagittal orientation and there are fewer than three sagittal images, the “sagittal” DICOM series should be renamed as a “scout” sequence of images. The image viewer presents the determined sequence name to the radiologist below the thumbnails 204 b.

In another example, the image viewer uses DICOM metadata, for example in the manifest file, to identify a first sequence of axial images as having a contrast agent and a second sequence of axial images as being without the contrast agent. In some implementations, the names of the sequences in the DICOM metadata do not indicate whether or nor the sequences include the contrast agent. The image viewer determines that the sequence of axial images without contrast agent and the sequence of axial images with contrast agent, should be named “with contrast” and “without contrast,” respectively. The image viewer presents the determined sequence names to the radiologist below the thumbnails 204 d-e.

In some implementations, the image viewer can reconstruct a scout sequence. For example, if the image viewer determines that the images are of a type that typically have a scout sequence and no scout sequence was found, then the image viewer can reconstruct a scout sequence using images from the other orientations. For example, CT axial images may typically have a scout sequence. If a sagittal or coronal scout sequence for the CT axial sequence is not identified during the sequence creation phase, then the image viewer can use image reconstruction techniques to generate one or more scout images from the CT axial images. The image viewer can create a sequence for the reconstructed scout images. The image viewer can give the scout sequence a name, such as “scout: reconstructed,” and places a thumbnail for the reconstructed scout image sequence in the GUI 200.

FIG. 3 shows another example of a GUI 300 for presenting medical images organized by relevance. The GUI 300 can be provided by an image viewer application. Particularly, the GUI 300 shows MRI images that may be medically relevant for an examination of the head of a particular patient. The GUI 300 includes multiple viewing panes 302 a-b and multiple thumbnails 304 a-f. Each of the viewing panes 302 a-b shows an image from a particular medically relevant sequence of images.

The viewing pane 302 a shows a sequence of axial images of the patient's head for a first MRI pulse sequence (“pulse 0”). The viewing pane 302 b shows a sequence of axial images of the patient's head for a second MRI pulse sequence (“pulse 1”). The thumbnails 304 a-f include representations of a sequence that includes “all” of the MRI images, a sequence that includes the “axial” MRI images, a sequence that includes “sagittal” images, a sequence that includes “coronal” images, a sequence that includes the axial “pulse 0” images (shown in the viewing pane 302 a), and a sequence that includes the axial “pulse 1” images (shown in the viewing pane 302 b), respectively.

The axial, sagittal, and coronal sequences were three DICOM series originally specified in the DICOM metadata for the MRI images. In this example the axial “pulse 0” images and the axial “pulse 1” images are interleaved in the DICOM axial series of images. The image viewer use the manifest file to determine that the MRI images include axial “pulse 0” and “pulse 1” images and accordingly creates separate sequences for the axial “pulse 0” and “pulse 1” images, represented by the thumbnails 304 e-f. The image viewer sorts through the MRI images and determines which of the MRI images are placed in the “pulse 0” and “pulse 1” sequences. That is the image viewer can use the manifest file to identify the MRI images that have an axial orientation and are either “pulse 0” or “pulse 1.”

The image viewer can place the MRI images in the “pulse 0” and “pulse 1” sequences in the order in which they occur in the axial DICOM series. In some implementations, the image viewer uses the position of the MRI images (e.g., a length measurement in centimeters along an axis through the patient from head to toe) to match images from “pulse 0” with images from “pulse 1.” This allows the GUI 300 to present the same, or similar, spatial image in the viewing pane 302 a and the viewing pane 302 b for two different magnetic resonance pulse sequences.

In some implementations, the image viewer can identify nuclear magnetic resonance (NMR) or MRI images associated with a longitudinal (spin-lattice) relaxation time, T₁, and a transverse (spin-spin) relaxation time, T₂. For example, the image viewer can examine the scan parameters in the copied DICOM metadata to identify if a delay time between a ping and a read is greater than a particular threshold. If the delay time for an NMR/MRI image is greater than the threshold, then the image viewer creates a T₂ sequence and places those images in the T₂ sequence. If the delay time for an NMR/MRI image is not greater than the threshold, then the image viewer creates a T₁ sequence and places those images in the T₁ sequence. The image viewer can also determine and present a name for the sequence, such as “longitudinal relaxation time,” “spin-lattice relaxation time,” or “T₁.”

In some implementations, the image viewer uses the copied DICOM metadata in the manifest file to identify secondary capture images. Secondary capture images can include, for example, screen captures performed by a medical technician operating the imaging modality. The medical technician can, for example, add comments or highlight portions of an image to assist the radiologist in interpretation of the image. Secondary capture images can have a lower resolution than the primary images generated by the particular modality. If the image viewer identifies secondary capture images, then the image viewer can create a sequence for the secondary capture images and place the images in the sequence for presentation using a GUI, such as the GUI 300.

In some implementations, the image viewer places the secondary capture images in a sequence having similar primary images. For example, the image viewer can place axial secondary captures images at the beginning of a sequence of axial primary images. In some implementations, the image viewer can identify, for a particular secondary capture image, a primary image that corresponds to the secondary capture image. For example, the secondary capture image may have a particular orientation as well as a position. The image viewer can identify a primary image having the same or similar orientation and position. The image viewer can then, for example, insert the secondary capture image into the sequence with the identified primary image just prior to the identified primary image.

In some implementations, the image viewer can use time and position information in the copied DICOM metadata to create image sequences. For example, a particular DICOM series of medical images can include a first set of images from a particular spatial position of a patient that are taken over time at a regular time interval. The DICOM series can include a second set of images taken, for example, a different spatial position or over time at a later point in time. The image viewer uses the time and position information to create a first time sequence for the first set of images and a second time sequence for the second set of images. The image viewer can identify the first set of images using, for example, the regular time interval and the common spatial position. The image viewer can identify the second set of images using, for example, a regular time interval of the second set and a spatial position common to the second set. In some implementations, the image viewer presents the two time sequences side-by-side in a GUI, such as the GUI 300. For example, the image viewer can have a rule to determine when to present time sequences viewing panes that are side-by-side, such as if the two time sequences have corresponding times or the same number of images.

In some implementations, the image viewer can further control the presentation of the sequences of medical images using information from the manifest file. For example, the image viewer can preselect a bone window level or bone density setting for the presented images based on the age of the patient (e.g., zero to eighteen years, nineteen to fifty-nine years, and sixty to one hundred years). The image viewer can use the patient birth date in the copied DICOM metadata to determine an age or age range for the patient. In another example, the image viewer can chose between a cine mode and a montage mode based on the number of images in the order or a sequence. Cine mode can, for example, allow a radiologist to scroll through sequences of images in the viewing panes. Montage mode can, for example, allow a radiologist to view a number of the images from a sequence at the same time using several viewing panes. For example, if a sequence includes four images, the image viewer can present all of the images using a two-by-two grid of viewing panes rather than having the radiologist scroll through the images using a single viewing pane.

In some implementations, the image server that creates the manifest file can add data to the manifest file in addition to the copied DICOM metadata. For example, an image server can add patient or examination information from a radiology information system (RIS) to the manifest file. The image viewer can use the RIS information in the manifest file to control the presentation or organization of medical images. For example, if the RIS information indicates that the examination is a body scan, then the image viewer can present multiple viewing panes for one or more of the image sequences in the order. If the RIS information indicates that the examination is a head scan, then the image viewer can present a limited number of viewing panes for the image sequences in the order to provide a larger view of the head scan images. In some implementations, the image viewer can compare the DICOM information to the RIS information to identify errors or incomplete data associated with medical images in an order.

In some implementations, the RIS information or other patient information can indicate that a similar image interpretation had been done for the patient in the past. The image server can send the prior images to the image viewer. The image viewer identifies the prior images and creates one or more image sequences for the prior images. The image viewer can present one or more of the prior image sequences together with corresponding image sequences from the current medical images being interpreted. In some implementations, the manifest file includes data that explicitly specifies a comparison read of images to be performed by the radiologist. In this example, the image viewer can also present corresponding sequences together in a GUI (e.g., side-by-side with link scrolling), such as in the GUI 300.

FIGS. 4 and 5, are flow charts showing an example of a process 400 and an example of a process 500, for organizing medical images by relevance. The process 400 and the process 500 may be performed, for example, by a system such as the teleradiology system 100. For clarity of presentation, the description that follows uses the teleradiology system 100 as the basis of an example for describing the process 400 and the process 500. However, another system, or combination of systems, may be used to perform the process 400 and the process 500.

Referring to FIG. 4, the process 400 for creating a manifest file for use in organizing medical images by relevance begins with receiving (402) a transmission that includes multiple medical images. The medical images may each include metadata that describes characteristics of the associated medical image. The metadata is inseparably encoded with the medical images. For example, the IO management system 102 can receive the medical images 108 a-c from the medical facility 104 a. The medical images 108 a-c include the metadata 110 a-c, respectively. The metadata 110 a-c in this example is inseparable from the medical images 108 a-c.

The process 400 extracts (404) a copy of the metadata from the medical images. For example, the image server 114 extracts a copy of the metadata 110 a-c from the medical images 108 a-c.

The process 400 generates (406) a manifest file based on the extracted copy of the metadata. The manifest file is configured to be transmitted independent of the transmission of the medical images. For example, the image server 114 generates the manifest file 112 a. The manifest file 112 a includes the metadata 110 a-c. In some implementations, the manifest file is generated using DICOM metadata, RIS information, or a combination of DICOM and RIS data.

The process 400 transmits (408) the manifest file to an image viewer for use in reordering the medical images into one or more medically relevant sequences for review by medical personnel. For example, the image server 114 transmits the manifest file 112 a to the client device 106 a.

Referring to FIG. 5, the process 500 for presenting medical images organized by relevance begins with receiving (504) a transmission that includes multiple medical images. The medical images each include metadata that describes characteristics of the associated medical image. The metadata is inseparably encoded with the medical images. For example, the image viewer application at the client device 106 a receives the medical images 108 a-c.

The process 500 receives (504) a transmission comprising a manifest file. The manifest file is transmitted independent of the transmission of the medical images and the manifest file is based on the metadata. For example, the image viewer application at the client device 106 a receives the manifest file 112 a. In some implementations, the client device 106 a receives the manifest file 112 a before receiving the medical images 108 a-c or before receiving all of the medical images 108 a-c. The image viewer can begin processing the manifest file 112 a without having received all of the medical images 108 a-c.

The process 500 reorders (506) the medical images, using the manifest file, into one or more medically relevant sequences for review by medical personnel. For example, the image viewer application can use the manifest file 112 a to reorder the medical images 108 a-c as described with respect to the GUI 200 and the GUI 300.

Optionally, the process 500 determines (508) one or more names, using the manifest file, for the one or more medically relevant sequences. For example, the image viewer application can use the manifest file 112 a to determine if an image sequence is a “scout” sequence, an “axial” sequence, or an MR “T₁” sequence.

The process 500 presents (510) one or more of the medically relevant sequences to the medical personnel. Optionally, the process 500 presents (512) the determined names of the medically relevant sequences to the medical personnel. For example, the image viewer application at the client device 106 a presents the medical images 108 a-c and the names of the sequences of medical images using a GUI, such as the GUI 200 or the GUI 300.

In some implementations, the image viewer application allows a radiologist or other medical personnel that reviews medical images to configure one or more sequences of images. For example, the image viewer can allow medical personnel to define rules for creating sequences, rules for including images in a sequence, and rules for ordering images within a sequence. In some implementations, the image viewer can store the rules and retrieve the rules for use during a subsequent image review session. The image viewer may associate the rules with a particular set of medical images or any set of medical images. The image viewer may associate the rule with a particular medical person (only applying the rules when that medical person is using the image viewer) or the image viewer may allow any medical personnel to use rules created the particular medical person.

FIG. 6 is a schematic diagram of a generic computing system 600. The generic computing system 600 can be used for the operations described in association with any of the computer-implement methods described previously, according to one implementation. The generic computing system 600 includes a processor 602, a memory 604, a storage device 606, and an input/output device 608. Each of the processor 602, the memory 604, the storage device 606, and the input/output device 608 are interconnected using a system bus 610. The processor 602 is capable of processing instructions for execution within the generic computing system 600. In one implementation, the processor 602 is a single-threaded processor. In another implementation, the processor 602 is a multi-threaded processor. The processor 602 is capable of processing instructions stored in the memory 604 or on the storage device 606 to display graphical information for a user interface on the input/output device 608.

The memory 604 stores information within the generic computing system 600. In one implementation, the memory 604 is a computer-readable medium. In one implementation, the memory 604 is a volatile memory unit. In another implementation, the memory 604 is a non-volatile memory unit.

The storage device 606 is capable of providing mass storage for the generic computing system 600. In one implementation, the storage device 606 is a computer-readable medium. In various different implementations, the storage device 606 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

The input/output device 608 provides input/output operations for the generic computing system 600. In one implementation, the input/output device 608 includes a keyboard and/or pointing device. In another implementation, the input/output device 608 includes a display unit for displaying graphical user interfaces.

The features described can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The apparatus can be implemented in a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by a programmable processor; and method steps can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).

To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.

The features can be implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination of them. The components of the system can be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include, e.g., a LAN, a WAN, and the computers and networks forming the Internet.

The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a network, such as the described one. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Although a few implementations have been described in detail above, other modifications are possible. For example, the client devices 106 a-b can receive the medical images 108 a-f from the medical facilities 104 a-b and generate the manifest files 112 a-b.

In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims. 

1-24. (canceled)
 25. A computer-implemented method for organizing images for display with use of a manifest, comprising: accessing medical imaging data, the medical imaging data including a plurality of medical images and including metadata for the medical images, and the metadata providing one or more image capture characteristics for respective medical images; extracting information from the metadata included in the medical imaging data; generating, from the extracted information from the metadata, a manifest separate from the medical images that identifies the one or more image capture characteristics of the medical image and provides data to organize at least a portion of the medical images into at least one new medical interpretation sequence; and transmitting the manifest to a client system; wherein the manifest is provided to the client system in a data format readable by the client system, enabling the client system to construct the at least one new medical interpretation sequence from the medical images using the data of the manifest, the at least one new medical interpretation sequence being undefined by the metadata of the medical imaging data.
 26. The method of claim 25, wherein at least one of ordering or grouping of medical images within the at least one new medical interpretation sequence is determined at the client system from the manifest using the one or more image capture characteristics described in the metadata.
 27. The method of claim 25, wherein extracting the information from the metadata comprises extracting one or more orientation characteristics for the medical images from the metadata, the orientation characteristics describing at least one orientation, relative to a patient depicted in the medical images, at which the medical images were acquired, and wherein generating the manifest comprises including information from the extracted orientation characteristics in the manifest; and wherein operations at the client system to construct the at least one new medical interpretation sequence include use of the extracted orientation characteristics from the manifest to organize the medical images into one or more sequences of images having substantially the same orientation.
 28. The method of claim 25, wherein extracting the information from the metadata comprises extracting at least one of one or more time characteristics and one or more position characteristics for the medical images from the metadata, the time characteristics and position characteristics respectively describing at least one time and at least one position at which the medical images were acquired, and wherein generating the manifest comprises including information from the extracted time and position characteristics in the manifest; and wherein operations at the client system to construct the at least one new medical interpretation sequence include use of the time and position characteristics from the manifest to organize the medical images into one or more time ordered sequences of images for a particular position.
 29. The method of claim 25, wherein extracting the information from the metadata comprises extracting one or more magnetic resonance (MR) pulse sequence characteristics from the metadata, and wherein generating the manifest comprises including information from the extracted MR pulse sequence characteristics in the manifest; and wherein operations at the client system to construct the at least one new medical interpretation sequence include use of the MR pulse sequence characteristics from the manifest to organize the medical images into one or more MR pulse sequences of images.
 30. The method of claim 25, wherein extracting the information from the metadata comprises extracting one or more contrast agent characteristics for the medical images from the metadata, the contrast agent characteristics identifying whether a contrast agent was present when the medical images were acquired, and wherein generating the manifest comprises including information from the extracted contrast agent characteristics in the manifest; and wherein operations at the client system to construct the at least one new medical interpretation sequence include use of the contrast agent characteristics from the manifest to organize the medical images into one or more sequences of images with a contrast agent and one or more sequences of images without the contrast agent.
 31. The method of claim 25, wherein extracting the information from the metadata comprises extracting information regarding a modality used to generate the medical images, including a type of the modality and one or more imaging parameters of the modality.
 32. The method of claim 25, wherein extracting the information from the metadata comprises extracting information that identifies one or more of the medical images as secondary capture images and one or more of the medical images as primary capture images, and wherein generating the manifest comprises including the information identifying the secondary capture images and the primary capture images in the manifest; and wherein operations at the client system to construct the at least one new medical interpretation sequence include use of the information from the manifest identifying the secondary capture images and the primary capture images, for placement of respective secondary capture images before or adjacent to corresponding primary capture images in the new medical interpretation sequence.
 33. The method of claim 25, further comprising retrieving, from a radiology information system, radiology data relevant to the construction of the at least one new medical interpretive sequence, the radiology data including one or more of patient data, examination data, imaging data, or scan data, wherein generating the manifest includes use of the retrieved radiology data.
 34. The method of claim 25, further comprising: transmitting the medical images to the client system, the medical images having a first ordering in one or more initial sequences, and the medical images including metadata in the medical images describing one or more characteristics of the medical images and a modality that generated the medical images; wherein operations at the client system to construct the at least one medical interpretation sequence include reordering, using the manifest, the medical images at the client system with at least one ordering algorithm, wherein the medical images are reordered for display of at least a second ordering associated with one or more medically relevant sequences, to facilitate the display of the at least second ordering of the medical images in the one or more medically relevant sequences at the client system.
 35. The method of claim 25, wherein operations at the client system to construct the at least one medical interpretation sequence includes evaluating one or more rules for creating medically relevant sequences and evaluating one or more rules for including and ordering the medical images in the medically relevant sequences.
 36. The method of claim 25, wherein generating the manifest comprises including one or more orientation characteristics for the medical images describing at least one orientation, relative to a patient depicted in the medical images, at which the medical images were acquired, and wherein operations at the client system to construct the at least one new medical interpretation sequence includes use of the orientation characteristics to organize the medical images into one or more sequence of images having substantially the same orientation.
 37. The method of claim 36, wherein operations at the client system to construct the at least one new medical interpretation sequence includes identifying at least one of the sequence of images having substantially the same orientation as a scout sequence when the orientation of the identified sequence is either sagittal or coronal.
 38. The method of claim 25, further comprising: receiving, from a medical facility, a transmission comprising the plurality of medical images and metadata describing one or more characteristics of the medical images and a modality that generated the medical images, wherein the metadata is included in the medical images; wherein the manifest catalogs the one or more characteristics of the medical images; and wherein transmitting the manifest to a client system comprises transmitting the manifest to an image viewer at the client system.
 39. The method of claim 25, wherein transmitting the manifest to a client system comprises transmitting the manifest to an image interpreter at the client system, wherein the image interpreter generates an automated initial diagnosis based on analysis of the medical images reordered into the at least one new medical interpretation sequence.
 40. A computer-implemented system for organizing images comprising: an interface configured to receive data originating from a medical imaging facility, the data comprising a plurality of medical images and metadata describing one or more characteristics of the medical images and a modality that generated the medical images, wherein the metadata is included in the medical images; a metadata extractor configured to extract information from the metadata; and a manifest generator configured to generate, based on the extracted information from the metadata, a manifest that catalogs the one or more characteristics of the medical images, wherein the manifest is transmitted to an image viewer at a client device for use in organizing the medical images into one or more medically relevant sequences for review by one or more medical personnel.
 41. The system of claim 40, wherein the interface is configured to transmit data to the client device, including the plurality of medical images and the manifest in separate data transmissions, wherein the medical images provide a first ordering in one or more initial sequences; wherein operations at the client system to construct the at least one medical interpretation sequence include reordering, using the manifest, the medical images at the client system for display in at least a second ordering associated with the one or more medically relevant sequences for review by one or more medical personnel, to facilitate display of the at least second ordering of the medical images in the one or more medically relevant sequences.
 42. The system of claim 41, further comprising: an imaging viewing client at the client device, configured to receive the manifest from the interface in a first transmission, and receive the medical images from the interface in a second transmission, the imaging viewing client configured to define the one or more medically relevant sequences of the medical images using the manifest, and the imaging viewing client providing an image viewer configured to display the medical images in the defined one or more medically relevant sequences.
 43. A computer-readable data storage medium storing computer-executable instructions that, when executed, perform actions in a computing system that: access medical imaging data, the medical imaging data including a plurality of medical images and including metadata for the medical images, and the metadata providing one or more image capture characteristics for respective medical images; extract information from the metadata included in the medical imaging data; generate, from the extracted information from the metadata, a manifest separate from the medical images that identifies the one or more image capture characteristics of the medical image and provides data to organize at least a portion of the medical images into at least one new medical interpretation sequence; and transmit the manifest to a client system; wherein the manifest is provided to the client system in a data format readable by the client system, enabling the client system to construct the at least one new medical interpretation sequence from the medical images using the data of the manifest, the at least one new medical interpretation sequence being undefined by the metadata of the medical imaging data.
 44. The computer-readable data storage medium of claim 43, wherein at least one of ordering or grouping of medical images within the at least one new medical interpretation sequence is determined from the manifest using one or more image capture characteristics described in the metadata.
 45. The computer-readable data storage medium of claim 44, further comprising: transmitting the medical images to the client system, the medical images having a first ordering in one or more initial sequences; wherein operations at the client system to construct the at least one medical interpretation sequence include reordering, using the manifest, the medical images at the client system for display in at least a second ordering associated with one or more medically relevant sequences for review by one or more medical personnel, to facilitate display of the at least second ordering of the medical images in the one or more medically relevant sequences. 